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ABSTRACT 


The  Satellite  Communications  Laboratory  at  the  .Naval  Postgraduate 
School  uses  a  PDP-11/34A  minicomputer  to  develop  software  in  support  of 
a  satellite  signal  monitoring  system.  The  General  Purpose  Interface  Bus 
(GPIB)  interconnects  several  general  measurement:  devices  used  ir.  support 
of  the  laboratory.  The  laboratory  uses  these  measurement  devices  for 
diagnostic  and  simulation  tests  related  to  research  in  the  suC'rLlite 
signal  monitoring  field.  This  thesis  discusses  the  development  of  the 
hardware  and  software  interface  between  the  PDP-11/34A  Unibus  and  the 
GPIB.  The  interface  permits  high  level  language  programs  unde:  the 
control  of  the  Unix  operating  system  (version  6)  on  the  PUP- 11/ 34 A  to 
access  any  device  on  the  GPIB 
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I.  INTRODUCTION 


The  Satellite  Communications  (SATCOM)  laboratory  at  the  Naval 
Postgraduate  School  utilizes  a  PDP-11/34A  minicomputer  as  a  research 
tool  for  satellite  signal  analysis.  The  General  Purpose  Interface  bus 
(GPIB)  interconnects  instrumentation  used  as  simulation  and  diagnostic 
tools  for  the  signal  analyzer's  computer  software.  Under  usual 
circumstances  a  small  desk  top  computer  such  as  the  HP-9825  and  the 
attached  computer  interface  card  (HP-98034A)  control  the  flow  of  signals 
along  the  GPIB.  In  this  configuration  the  GPIB  devices  make  up  a 
separate  system  from  the  PDP-11 /34A  controlled  system.  Bringing  the 
GPIB  devices  under  control  of  the  PDP-11 /34a  requires  a  hardware  and 
software  interface  between,  the  minicomputer  Unibus  and  the  GPIB.  The 
interface  eliminates  the  need  for  the  HP-9825  and  HP-98034A.  The 
following  sections  discuss  the  characteristics  of  the  hardware  and 
software  interface  between  the  two  bus  systems. 

There  are  six  main  sections  in  this  thesis.  The  remainder  of  the 
introduction  explains  the  rationale  for  developing  the  interface  3na 
discusses  development  design  constraints.  The  next  section  discusses 
the  characteristics  of  the  Unibus  and  the  GPIB.  The  following  section 
treats  the  hardware  implementation  and  physical  structure  of  the 
interface  in  concert  with  the  Unibus  and  the  GPIB.  The  Unix  operating 
system  is  then  discussed,  especially  in  the  areas  of  I/O  and  system 
reconfiguration.  The  following  section  deals  with  with  the  software 
required  to  drive  >  he  hardware  under  the  constraints  and  requirements  of 
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the  Unix  operating  system.  The  contusion  summarizes  the  hardware  and 
software  characteristics  of  tne  interface  and  suggests  possible 
alternatives  and  amendments  to  the  existing  system.  The  conclusion  also 
provides  a  comparison  of  the  developed  interface  with  a  commercially 
available  product. 

A.  RATIONALE  FOR  INTERFACE  DEVELOPMENT 

With  no  interface  in  place  the  ?DP-ll/34a  system  ar.o  the 
simulation/diagnostic  device  system  are  independent.  The  PDP-11 /3'-.i  nas 
no  way  to  communicate  with  any  of  the  GPI3  equipment,  and  an  independent 
computer  (e.g.,  the  HP-9825)  controls  the  the  GPIB  devices. 
Additionally,  the  simulation/diagnostic  system  is  constrained  to  operate 
under  the  limited  flexibility  of  the  desk  top  computer  software.  <ith 
the  interface  in  place  an  operator  may  control  all  the  devices  on  the 
GPI3  from  a  console  on  the  PDP-11/34A  system.  The  operator  may  write 
programs  under  the  UNIX  operating  system  using  the  higher  level  C 
language  and,  treating  the  GPIB  as  just  another  peripheral  device,  rend 
or  receive  data  over  the  GPIB. 

In  summary  there  are  three  advantages  to  interfacing  tne  two 
systems: 

1.  The  need  for  the  desk  top  computer  is  deleted. 

2.  One  Unibus  console  controls  both  systems. 

3.  Unix  operating  system  software  drives  the  GPIB. 

Figure  1.1  is  a  block  diagram  of  an  interfaced  system  to  illustrate  the 
effect  of  the  GPIB  interface. 
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UN! BUS 


GPIB 


Fig  1.1  PDP-11  Instrumentation  System 


B.  INTERFACE  DESIGN  DEVELOPMENT 


The  design  of  the  GPIB  interface  is  subject  to  two  major 
constraints.  First,  the  hardware  cor  the  interface  must  not  take  up 
more  than  one  slot  within  the  PDP-11 /34A  mainframe.  In  other  words, 
total  board  size  must  not  exceed  a  single  hex-height  card.  Second,  the 
software  to  interface  the  systems  must  conform  to  the  I/O  requirements 
of  the  Unix  operating  system. 

The  following  sections  discuss  the  hardware  and  software 
implementation  of  the  GPIb  interface  oased  on  the  needs  ana  constraints 
discussed  in  the  preceding  paragraphs.  The  hardware  development  is 
discussed  first  since  it  is  inoependent  of  the  operating  system  of  the 
computer.  The  software  development  is  preceded  by  a  treatment  of  the 
Unix  operating  system  and  in  particular  the  Unix  I/O  area. 


II.  UNIBUS  AND  GPIB  CHARACTERISTICS 


The  hardware  and  software  interface  implementation  connects  two 
independent  bus  systems,  Unibus  and  GPIB.  Discussion  of  the  Unibus  is 
limited  to  a  brief  description  since  no  hardware  or  software  changes  are 
required  on  the  DR11-C  General  Purpose  Interface  module,  which  initially 
interfaces  the  'Jnibus ,  beyond  address  wire  jumper  connections.  Digital 
Equipment  Corporation  supplies  information  on  the  detailed  operation  and 
characteristics  of  the  Unibus  [Ref.  1:  pp.  2-20].  The  discussion  of  the 
GPIB  is  more  descriptive  since  the  data  transfer  and  handshaking 
requirements  of  that  system  directly  govern  the  design  of  the  hardware 
and  software  needed  t:o  connect  the  DR11-C  and  the  GPIB. 


A.  UNIBUS 


The  PDP- 

-J  i  I  ni  bus 

is  composed  of 

56  bidirectional  lines  which 

carry 

signals  among  devices 

on  the  bus 

(CPU 

,  memory,  I/O).  Of  these  56 

lines , 

the  DRU-C 

uses  45 

[Ref.  2: 

pp. 

8-9].  These  signals  and 

the:  r 

respective 

functions 

are  in 

table 

4  of  the  DR11-C  Instruction 

Manual 

[Ibid.].  A 

thorough 

analysis 

of 

the  Unibus  operation  and 

signal 

characteristics  is  available  in  the  support  literature. 

B.  GPIB 

The  General  Purpose  Interface  Bus  (GPIB)  is  a  16  line  bidirectional 
bus  which  meets  the  requirements  of  the  IEEE-488-1975  standard.  It  is 
designed  to  facilitate  the  exchange  of  data  among  devices  connected  to 
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the  bus.  The  Hewlett-Packard  implementation  of  the  GPIB  is  called  the 
HP-IB,  and  thus  the  terms  GPIB  and  HP-IB  have  interchangeable  meanings. 

This  section  contains  only  a  limited  discussion  of  GPIB 
characteristics.  Reference  material  [Ref.  3  and  Ref.  4]  concerned  with 
the  analysis  of  the  bus  is  available  which  provides  a  thorough  treatment 
of  the  GPIB  signals  and  capabilities.  Table  II. 1  describes  the  signal 
lines  on  the  GPIB  which  control  activity  on  the  bus.  In  addition  to 
those  listed,  there  are  eight  lines  designated  to  carry  data  among 
devices  on  the  bus.  As  seen  in  Table  II. 1,  all  signals  on  the  GPIB  are 
negative-true  polarity.  That  is,  a  high  signal  means  false,  and  a  low 
signal  means  true.  In  order  to  ensure  clarity,  subsequent  discussion  of 
the  term  "DATA"  (all  capitals)  refers  to  the  eight  lines  which  carry 
information  between  devices,  while  "data"  refers  to  the  16  bit  contents 
of  the  bus  or  a  register  in  the  system. 

One  device  on  the  bus  is  designated  as  the  active  controller.  The 
active  controller  issues  instructions  to  other  devices  and  controls  all 
the  traffic  on  the  bus.  Any  device  may  be  designated  as  an  active 
controller,  but  this  job  is  usually  assigned  to  a  computer  or 
calculator . 

One  device  on  the  bus  is  designated  as  the  system  controller.  The 
system  controller  is  established  through  hardware  connections  and  cannot 
be  passed  to  another  device  on  the  bus.  The  system  controller 
automatically  becomes  the  active  controller  when  power  is  turned  on  or 


the  bus  is  reset 
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Table  11.1  GPIB  Signal  Descriptions 


1.  Data  Transfer 


Though  there  are  eight  lines  available  for  DATA  (01  through  Do) 
most  of  the  GPIB  instruments  base  their  DATA  on  the  seven  bet  ascii 
code.  DATA  is  transferred  ascii  character  at  a  time,  oyte  serial  and  bit 
parallel.  For  the  GPIB  interface  all  DATA  is  presumed  to  be  ascii 
coded.  Therefore,  only  seven  DATA  bits  are  implemented  on  the  CPI- 
interface. 

Transfer  of  data,  whether  in  a  read  or  write  context,  is 
initiated  by  the  active  controller  which  establishes  the  talker/listencr 
relationship  among  the  devices  on  the  bus.  The  active  controller  sends 
the  talker  device  number  and  the  listener  device  number  over  the  DATA 
lines  with  the  ATN  signal  true.  While  ATN  is  true,  the  devices  on  trie 
bus  interpret  DATA  as  bus  control  messages  rather  than  actual  da!:--, 
messages.  Once  the  talker  and  listener  are  designated  the  active 
controller  sets  ATN  false  which  signals  the  talker  to  begin  sending  ii:* 
data  message  over  the  DATA  lines.  Designation  of  the  tai.Ker  arc 
listener  is  usually  preceded  by  an  UNLISTEN  bus  command  from  tie 
computer  which  effectively  resets  the  bus  for  DATA  flow. 

2.  Handshaking 

Handshaking  is  the  term  used  to  describe  the  process  whereby  .? 
controlling  device  and  a  peripheral  device  talk  to  one  another  curing 
an  exhange  of  data.  In  the  GPIB  handshaking  process  the  talker  notifies 
a  listener  of  available  DATA.  The  listener  signals  both  readiness  for 
DATA  and  completion  of  DATA  processing.  The  process  on  the  GPIB  is 
asynchronous,  and  no  restrictions  are  placed  on  the  data  rates  of  any 
instrumentation  on  the  bus.  Because  of  the  asynchronous  nature  of  the 
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DATA  exchange  and  handshaking  process,  the  slowest  device  on  the  tiie 
GPIB  (e.g.,  a  printer/plotter)  controls  the  time  required  to  complete 
the  entire  procedure. 

Handshaking  is  under  the  control  of  three  signals  on  the  bus: 
DAV,  NRFD,  and  NDAC.  The  talker  controls  the  DATA  lines  and  DAV.  The 
listeners  control  NRFD  and  NDAC.  The  following  description  of  the 
handshaking  process  is  illustrated  in  Figure  2.1.  The  process  is  the 
same  for  bus  commands  as  well  as  for  data  message  transfer. 

DATA  transfer  is  initiated  by  all  the  listeners  on  the  bus  by 
setting  NRFD  high.  This  signifies  that  they  are  ready  for  DATA  (Not 
Ready  For  Data  is  false).  When  the  talxer  senses  that  the  NRFD  line  is 
high  it  places  DATA  on  the  DATA  lines  and  sets  the  DAV  line  low  (Data 
Available  is  true).  When  the  addressed  listener  senses  that  DAV  is  low 
it  takes  in  the  data,  processes  it  and  signifies  when  processing  is  over 
by  setting  NDAC  high  (Not  Data  Accepted  is  falsa)  which  tells  the  talker 
that  the  DATA  has  been  accepted  and  it  no  longer  need  oe  held  on  the 
DATA  lines.  When  the  talker  senses  NDAC  is  high  It  sets  DAV  high 
(false)  while  it  places  the  next  DATA  byte  on  the  DACA  lines.  When  DAV 
is  sensed  as  high  by  tne  listener,  it  sets  the  NDAC  line  back  low  then 
NRFD  high  to  start  the  cycle  over.  Note  that  both  NRFD  and  NDAC  cannot 
be  high  at  the  same  time.  Such  a  state  is  illegal. 

The  assertive  state  of  NDAC  and  NRFD  is  high.  Since  all  the 
listeners  have  their  repective  bus  lines  tied  together,  all  listeners 
must  set  their  corresponding  signals  high  before  that  line  on  the  GPIB 
goes  high.  This  is  the  wired  AND  situation  which  allows  the  talker  to 
recognize  when  the  slowest  device  has  taken  the  DATA  and  is  ready  for 
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:  Listener  ready  for  data 

:  Data  placed  on  data  lines  by  talker 
:  Data  on  data  lines  valid 
:  Data  accepted  by  listener 

:  Data  no  longer  valid  and  may  be  changed  by  talker 
:  Listener  ready  for. new  data 
:  Cycle  repeats 

Curved  arrows  indicate  interlocked  signal  sequence. 

Fig  2.1  GPIB  Handshake  Sequence 


more.  All  listeners  on  the  bus  respond  to  the  talker.  Only  the 
addressed  listener,  however,  processes  that  DATA  as  a  message. 

C.  SUL- CLARY 

The  General  Purpose  Interface  Bus  (GPIB)  is  a  16  line  bus  system 
intended  for  use  primarily  with  instrumentation  utilizing  the  seven  bit 
ascii  code  for  data  transfer  in  a  serial  byte  and  parallel  bit  mode.  The 
Unibus  is  a  56  line  system  which  is  driven  by  the  PDP-11  CPU.  In  order 
for  the  PDP-11  to  communicate  with  a  device  on  the  GPIB  the  data  must 
pass  over  the  Unibus  data  lines,  through  the  GPIB  interface,  onto  the 
GPIB,  and  into  the  device.  As  will  be  seen  in  section  III,  the  DR11-C 
handles  the  excnange  of  data  and  handshaking  signals  from  the  Unibus 
without  modification  of  the  DR11-C  module  or  software  assistance. 
However,  exhange  of  data  between  the  GPIB  and  the  DR11-C  and  then  onto 
the  desired  device  requires  additional  hardware  and  software  support. 
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III.  HARDWARE  IMPLEMENTATION 


The  GPIB  interface  hardware  relationships  between  the  b'nibus  and  the 
GPIB  are  illustrated  in  the  block  diagram  in  Figure  3.1.  The  hardware 
for  the  interface  consists  of  one  DRll-C  general  purpose  interface 
module  (hereafter  referred  to  as  the  DR11-C),  and  a  locally  designed  and 
constructed  buffer  module,  called  the  CCI.  The  DRll-C  was  chosen  to 
intially  interface  the  Linibus  since  MDB  Incorporated ,  manufacturer  of 
the  DR11-C,  specifically  designed  it  to  act  "as  an  interface  to  transfer 
data  between  a  Digital  Equipment  Corporation  PDP-11  Uni'.^s  and  the 
user's  peripheral  device."  [Ref  2:  p.l]  The  DRll-C  is  therefore 
specifically  designed  to  transfer  16  data  bits.  In  the  following 

I 

discussion  the  terms  "data"  and  "data  bits"  refer  to  the  16  elements  of 
a  word  in  the  PDP  system.  When  referring  to  the  specific  elements  of 
the  GPIB  which  carry  the  ascii  character  (the  seven  least  significant 
bits)  the  term  "DATA"  is  used.  Since  the  GPIB  is  a  16  line 
bidirectional  bus,  the  DRll-C  is  well  suited  to  act  as  the  initial 
transfer  medium  for  the  interface  if  the  handshake/bus  command  lines  of 
the  GPIB  are  treated  in  software  as  data  bits.  The  CCI  board  is 
required  to  act  as  a  buffer  between  the  two  distinct  (input  and  output) 
registers  on  the  DRll-C  and  the  single  bidirectional  GPIB  connector. 

This  section  describes  the  GPIB  interface  hardware:  DRll-C  and  CCI. 
The  discussion  of  the  DRll-C  is  limited  to  a  functional  description 
since  the  DRll-C  instruction  manual  describes  the  interface  board  in 
detail,  providing  figures  and  schematics  to  assist  in  future  DRll-C 


UN  I  BUS 


Fig  3.1  GPIB  Interface  Component  Block  Diagram 


implementation.  The  CCI  board  is  discussed  in  greater  detail  iir.ce  Cue 
available  documentation  on  it  is  limited. 


A.  UR11-C  INTERFACE 

The  DR11-C  board  functionally  accepts  16  data  bits  iron  the  Unibus. 
sends  16  data  bits  to  the  Unibus,  and  performs  necessary  handshaking  in 
the  process.  A  full  description  of  Unibus/DRl i-C  data  transfer  is 
available  in  pages  10-12  of  the  DR11-C  Instruction  Manual. 

1 .  Registers 

The  DR11-C  has  three  registers:  control/status,  output,  anc 
input.  All  three  registers  are  16  bits  wide,  but  the  control/status 
register  uses  only  six  bits  of  the  16.  The  board  is  wired  such  tnat  the 
address  of  the  output  register  is  two  locations  greater  than  the 
control/status  register,  and  the  input  register  is  two  locations  greeter 
than  the  output  register.  In  other  words,  the  three  registers  occupy 
consecutive  16  bit  memory  locations  in  the  PDP-11  memory  space. 

The  DR11-C  is  manufactured  with  the  control/status  register 
wired  to  address  767770  (all  addresses  are  written  in  octal).  ibis 
address  may  be  changed  by  wired  jumper  as  discussed  on  page  7  of  the 
DR11-C  Instruction  Manual.  The  address  of  the  control /status  register 
is  set  to  address  767730  for  use  in  the  SATCOH  laboratory.  This  was 
done  in  accordance  with  the  instructions  on  page  15  of  the  DR11-C  Manual 
which  requires  that  the  address  of  the  control/status  register  on  the 
DR11-C  be  in  concert  with  the  associated  vector  address  [Ref.  2:  p.  15]. 
The  vector  address  must  be  chosen  such  that  it  is  higher  than  the  vector 
address  of  any  KL-11  in  the  system.  Unix  maK.es  use  of  the  KL-il  drivers 
for  the  teletype  consoles.  To  assign  the  vector  address  for  the  DR11-C 
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one  must  check  the  Unix  software  fiie  l.s  which  contains  the  vector 
address  assignments  for  the  system  (Unix  filenames  appear  in  single 
quotes).  From  this  file,  the  KL-ll's  occupy  veccot  addresses  300 
through  330.  Therefore,  we  assign  the  LiRll-C  the  vector  pair  340,344. 
The  corresponding  control/status  register  adaress  is  747730  [Ibid.]. 

Figure  3.2  illustrates  the  relationship  among  the  three  DR11-C 
registers  and  their  memory  locations.  In  the  PDP-11  memory  structure 
each  word  is  made  up  of  a  high  and  low  byte  of  eight  bits.  The  register 
location  is  identified  by  the  low  (even  numbered)  byte  adaress.  For 
example,  the  control/status  register  of  the  DRil-C  is  identified  with 
address  767730  but  includes  767731. 


B.  CCI  BUFFER/DRIVER  BOARD 

The  CCI  board  is  a  locally  constructed  interface  designed  to  resolve 
the  connector  mismatch  between  the  DR11-C  and  the  GP1L,  provide  logic 
reversal  for  the  negative-true  GPIB  from  the  posi tive-tri.e  DR.  1-C,  plus 
provide  a  means  for  the  output  register  of  the  DR11-G  to  feed  to  its 
input  register.  These  features  are  discussed  in  the  following 
paragraphs  with  a  description  of  the  Col  wiring  system. 

1 •  Connectors 

The  CCI  board  has  three  connectors:  Two  of  these  connect  to 
the  input  and  output  register  connectors  of  the  BR11-C  board,  and  one 
connects  to  the  bidirectional  GPIB.  Figure  3.3  depicts  the  physical 
makeup  of  the  connectors  and  their  designation  together  with  the  data 
flow  through  the  interface. 
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Table  I  I  1.1  Interface  Connector  Pin  Assignments 


Since  the  DRli-C  I/O  registers  are  16  bits  wide  and  the  GPIb  is 
a  16  line  bus,  a  one-to-one  correspondence  between  the  registers  and  the 
GPIB  is  used.  That  is,  each  line  of  the  GPI3  feeds  into  one  bit 
position  of  the  input  and  output  registers  of  the  DRli-C.  The  bit 
assignments  of  the  DRll-C  registers  are  shown  in  Figure  3.4.  The  ground 
line  from  the  GPIB  does  not  have  a  partner  connection  on  the  DR11-C 
registers,  since  the  CCI  nodule  provides  grounding  to  the  computer 
mainframe.  Therefore,  one  bit  position  on  those  registers  is  not  used. 
The  bit  assignment  for  the  input  register  is  identical  to  that  of  the 
output.  The  assignment  of  bit  positions  is  arranged  so  that  the  lower 
byte  of  each  register  contains  the  DATA  (plus  the  ATN  bit),  and  the 
higher  byte  contains  the  bus  control/handshaking  bits. 

The  GPIB  is  wired  to  botn  the  input  and  output  registers  on  the 
DRli-C  so  that  it  may  receive  DATA  and  bus  commands  from  the  output 
register  and  supply  DATA  and  bus  commands  to  the  input  register  without 
the  use  of  a  switch  boards.  Table  III.l  shows  the  pin  designations  for 
the  connectors  shown  in  Figure  3.3. 

2.  Signal  Inversion  And  Feedback 

The  GPIB  handshaking  process  requires  that  the  handshake 
signals  on  the  bus  be  monitored  as  they  are  toggled  by  the  talker  and 
listener.  The  Unibus  will  always  be  a  either  a  talker  or  a  listener 
when  the  interface  is  in  use,  and  thus  requires  a  register  to  monitor 
GPIB  handshake  activity.  The  register  used  for  this  purpose  is  the 
DRll-C  input  register.  Therefore,  both  the  GPIB  and  the  DRli-C  output 


register  must  have  means  to  transfer  data  to  the  input  register. 


However,  when  the  GPIB  transfers  data  tiie  DRli-C  output  register  must  be 
protected  against  having  its  contents  altered.  The  inverters  prevent 
the  undesirable  feedback  from  the  GPIB  to  the  output  register  while 
conveniently  inverting  the  positive-true  contents  of  the  output  register 
to  the  negative-true  GPIB  (see  Figure  3.3). 

There  exists  an  inconvenience  in  the  CCI  board  as  it  is 
currently  implemented.  The  data  returned  to  the  input  register  is  the 
inverse  of  that  in  the  output  register.  Although  inconvenient  this  is 
corrected  in  the  software  of  the  driver  routine.  In  view  of  the  size 
limitation  of  the  CCI  board,  the  software  method  of  resolving  the 
polarity  difference  is  more  practical  than  wiring  on  another  set  of 
inverters  to  the  single  height  board. 

3.  Wiring  System 

Figure  3.5  is  a  condensed  schnatic  of  the  wiring  system  of  the 
CCI  board.  A  full  schematic  [Ref.  5]  is  available  in  the  SATCOM  lab. 
Data  flow  through  all  lines,  except  the  REN  line,  are  identical  and  are 
represented  by  one  line  labled  with  the  indicated  letters  at  pinout 
positions.  Table  III. 2  lists  the  relationship  between  each  line  and  its 
associated  inverter  chip,  resistor  pin,  connector  designations,  and  pin 
numbers . 

The  REN  line  has  one  additional  inverter  in  its  line  to  provide 
the  user  with  a  default  position  of  true  rather  than  false.  Two 
inverters  are  provided  so  that  the  REN  line  may  be  made  to  default  to 
false  through  bypassing  one  of  the  inverters  with  a  hardwire  change. 
This  eliminates  the  need  to  change  software  in  the  driver  routine  or 
install  a  new  inverter  in  the  CCI. 
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C.  SUMMARY  OF  HARDWARE  IMPLEMENTATION 

The  DR11-C  and  the  CCI  buf f er/driver  boards  act  as  a  single 
interface  card  for  transfer  of  data  between  the  Unibus  and  GPIB.  The 
design  of  the  interface  is  provided  for  software  which  treats  the 
handshaking/bus  command  lines  in  the  same  way  as  DATA.  This  design  has 
nc  hardwire  connections  to  the  control/status  register  of  the  DRll-C. 
Therefore,  transfer  of  data  is  independent  of  the  interrupt  system.  All 
bit  checking  and  DATA  transfer  is  accomplished  through  manipulation  of 
the  DRll-C  output  and  input  registers.  The  input  register  serves  dual 
duty  as  a  register  to  read  DATA  from  the  GPIB  ana  to  provide  a  location 
to  monitor  the  status  of  handshaking/bus  command  lines  on  the  GPIB. 
Prior  to  the  discussion  of  the  software  to  support  the  above  hardware 
implementation,  the  Unix  operating  system  is  thoroughly  discussed  to 
provide  the  system  requirements  of  I/O  driver  software. 


IV.  UNIX  OPERATING  SYSTEM 


This  section  contains  a  general  discussion  of  the  Unix  operating 
system  as  installed  in  the  SATCOM  laboratory.  Attention  is  focused  on 
the  I/O  area  and  the  procedure  for  reconfiguration  of  the  operating 
system  when  a  change  is  made  to  the  I/O  drivers  and  support  software. 

A.  GENERAL 

The  Unix  operating  system  is  a  multi-user,  interactive  operating 
system.  A  full  assortment  of  documentation  and  manuals  are  available 
which  fully  describe  the  system.  These  are  primarily  the  work  of  Lennis 
M.  Ritchie,  Ken  Thompson,  and  Brian  W.  Kernighan  of  Bell  Laboratories 
who  developed  the  system  through  a  series  of  versions  beginning  in  196S. 
For  the  purposes  of  this  report  the  user  is  presumed  to  have  a  working 
knowledge  of  Unix  or  has  access  to  the  support  manuals. 

The  most  significant  feature  of  Unix  which  impacts  on  the  interface 
between  the  Unibus  and  GPIB  is  that  Unix  treats  virtually  everything  as 
a  file.  Text,  programs,  functions,  and  even  peripheral  devices  are  all 
associated  with  a  file.  The  reader  is  referred  to  the  in  depth 
treatment  of  the  Unix  file  system  by  Ritchie  and  Thompson  [Ref.  6]  if 
any  restructuring  of  the  operating  system  is  planned. 

Also  significant  is  the  fact  that  Unix  is  dominated  by  use  of  the  C 
programming  language.  Some  files  are  written  in  the  Unix  assembly 
language  (see  Kef.  7  for  details  of  the  Unix  assembler)  but  the  vast 
majority  are  written  in  C.  There  is  no  attempt  here  to  fully  discuss 
the  C  programming  language.  Ritchie  [Ref.  8  and  Ref.  9]  provides  a  very 
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readable  treatment  of  C  in  a  tutorial  format.  Again,  the  reader  is 
presumed  to  have  a  working  knowledge  of  the  C  language  or  access  to  the 
referenced  manuals. 

B.  UNIX  I/O 

In  order  to  implement  a  hardware  and  software  interface  between  the 
Unibus  and  GPIB,  a  thorough  understanding  of  the  Unix  I/O  system  is 
required.  Though  most  of  the  following  information  is  located  in  one  or 
more  of  the  manuals  listed  in  the  bibliography  or  list  of  References, 
there  is  no  one  source  to  which  a  user  may  turn  without  sifting  through 
a  plethora  of  unnecessay  text.  More  importantly  there  are  subtle 
differences  in  the  system  installed  in  the  SATCOM  laboratory  which  are 
not  reflected  in  the  support  manuals.  These  differences  will  be  noted 
as  they  occur  in  this  discussion.  Additionally,  references  to  Unix  I/O 
devote  much  effort  to  distinguish  between  transfer  of  a  block  of 
information  and  the  transfer  of  a  single  character.  This  work  will  only 
deal  with  character  transfer  since  the  GPIB  interface  is  equipped  only 
to  handle  one  character  at  a  time. 

1 .  Device  Drivers 

Every  I/O  device  on  the  Unibus  is  associated  with  a  device 
driver  (sometimes  called  a  handler)  which  interfaces  the  Unibus  with  the 
device.  The  driver  contains  a  minimum  of  four  routines  if  it  is  capable 
of  both  reading  and  writing.  These  routines  are  open,  close,  read,  and 
write.  The  contents  of  each  routine  varies  depending  on  the  device,  but 
their  purpose  is  common  to  all  devices.  That  is,  they  supply  the  Unix 
calls  of  the  same  name  with  the  instructions  necessary  to  cause  a 
satisfactory  interfacing  between  the  device  and  the  operating  system. 


34 


Because  of  their  importance  to  the  structure  of  the  device  driver,  each 
of  the  open,  close,  read,  and  write  calls  are  briefly  discussed  in  the 


following  paragraphs. 

The  open  call  has  the  form:  open(argl ,arg2) .  Open  is  called 
each  time  a  file  is  to  be  read  from  or  written  to.  Argi  is  the  full 
device  name  and  arg2  is  0,1,  or  2  depending  if  the  file  is  tc  read  from 
(0),  written  to  (1),  or  both  (2).  The  file  is  the  driver  containing  the 
read  and  write  routines.  The  open  routine  acts  as  a  sentr’'  to  allow 
only  one  user  to  access  the  drivers  read  and/or  write  routine  at  any  one 
time.  For  instance,  if  user  A  desires  to  write  on  a  paper  punch  the 
open  routine  checks  to  ensure  no  one  else  is  currently  using  that  paper 
punch.  If  user  B  has  already  accessed  the  punch  and  is  occupying  the 
machine  at  the  time  of  A's  request,  tne  open  routine  returns  an  I/O 
error  to  user  A.  If  user  E  is  not  using  the  punch  the  open  routine 
returns  a  single  digit  integer  called  a  file  descriptor  which  is  used  in 
subsequent  calls. 

The  close  call  has  the  form:  close(fd).  The  close  routine  is 
the  partner  of  the  open  routine.  When  the  user  is  finished  reading  from 
or  writing  to  the  file,  the  close  routine  takes  the  rile  descriptor 
returned  by  open  and  resets  the  driver  for  access  by  another  user.  The 
close  routine  is  called  once  for  every  call  on  open. 

The  read  call  has  the  form:  read(fd,buf ,nbytes).  The  read  call 
uses  the  file  descriptor  returned  by  a  successful  open  call  to  identify 
which  read  routine  will  be  used  to  process  the  read  request.  The  'fd' 
notation  is  commonly  used  throughout  the  Unix  reference  manuals  to 
denote  the  integer  value  for  the  file  descriptor.  'Buf'  is  the  name  of 


a  buffer  into  which  read  data  is  piacec.  'Nbytes '  is  the  number  of 
characters  to  be  placed  in  the  buffer. 

The  write  call  has  the  form:  wri te(fd ,buf .nbytes ) .  The  write 
call  performs  in  the  same  manner  as  the  read.  The  only  difference  is 
that  the  read  call  may  not  actually  read  as  many  as  'nbytes'  characters. 
If  the  device  supplies  only  10  characters,  10  will  be  read,  even  if  IOC 
are  requested.  The  write  call  considers  the  number  of  characters  to  be 
transferred  an  order,  not  a  request. 

Each  device  capable  of  being  read  from  and  being  written  to 
must  have  an  associated  driver  containing  an  open,  close,  read,  and 
write  routine.  The  routines  determine  how  the  open,  close,  read,  and 
write  calls  are  handled.  A  device  which  operates  with  interrupts  also 
contains  a  routine  to  determine  how  interrupts  are  handled. 
Additionally,  there  nay  be  a  special  function  routine  in  the  driver 
which  performs  a  particular  action  for  that  device.  Other  routines  may 
appear  in  a  driver  but  they  are  called  out  from  within  the  open,  read, 
write,  or  close  routines. 

In  the  foregoing  discussion  it  is  important  to  distinguish 
between  call  and  routine.  The  call  is  user  generated  software  with  user 
supplied  arguments.  The  routine  is  the  system  software  residing  in  the 
driver  which  determines  how  the  call  is  handled.  The  rules  assigned  to 
the  use  of  the  each  call  may  be  amended  if  the  routine  servicing  the 
call  is  changed. 

2.  I/C)  Support  Software 

If  the  GPIB  interface  involved  only  the  amending  of  an  existing 
driver,  little  effort  would  be  needed  to  edit  the  driver  and  reconfigure 
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the  system.  Unfortunately,  the  Unix  operating  system  at  the  SATCOtl 
laboratory  has  no  installed  software  for  such  an  interface.  Therefore, 

one  must  be  able  to  create  a  driver  and  then  reconfigure  the  system  to 
make  the  driver  operational.  Several  files  are  involved  with 
reconfiguration  and  are  essentially  independent  of  the  form  of  the 
driver  software,  so  long  as  the  driver  is  written  in  the  C  language  and 
consists  of  the  routines  previously  mentioned.  These  files  will  be 
discussed  here  to  simplify  the  description  of  the  reconfiguration 
process  which  follows. 

Filenames  in  Unix  follow  a  few  important  rules.  Files  which 
are  written  in  the  C  language  which  are  to  be  compiled  by  the  C  compiler 
must  have  the  form  'filename .c '  while  their  compiled  code  takes  on  the 
form  ' f ilename.o ' .  For  the  few  assembly  language  programs  the  form  is 
'filename. s'  for  the  source  code  and  'filename. o'  again  for  the 
assembled  version.  Files  with  no  suffix  may  be  directories,  executable 
programs,  or  text.  The  following  paragraphs  address  the  files  which 
directly  impact  on  I/O.  Figure  4.1  is  provided  to  assist  the  user  in 
locating  the  files  mentioned. 

The  'dev'  directory  contains  the  Unix  special  files  for  I/O. 
Each  device  on  the  Unibus  is  associated  with  a  special  file.  The 
listing  of  dev  is  different  from  all  other  directories,  containing  the 
major  and  minor  device  numbers  associated  with  the  device.  Each  device 
has  its  own  major  device  number  as  designated  in  the  'cO.c'  file 
discussed  later.  If  one  driver  applies  to  several  devices  of  the  same 
type  (such  as  teleypes)  the  minor  device  number  is  used  to  identify  each 
member  of  that  device  type.  The  only  way  to  make  an  entry  into  the 
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directory  'dev'  is  through  the  mknod(VIII)  command  which  requires  the 
device  numbers  as  part  of  its  argument  list.  The  files  in  the  'dev' 
directory  are  named  when  initiating  the  open  call  as  argl  in 
open(argl ,arg2) .  For  example,  to  open  the  write  routine  of  ttyl  call 
open(argl ,2) ,  where  argl  is  the  address  of  the  pathname  '/dev/ttyl'. 

The  file  'dmr'  contains  all  the  source  code  for  drivers  which 
are  currently  used  by  the  system.  The  source  code  for  drivers  which  are 
not  being  used  is  kept  in  the  file  'useless'  which  is  in  the  same 
directory,  'sys',  as  'dmr'.  The  source  code  does  not  directly 
participate  in  the  reconfiguration  process,  but  serves  as  a  workbench 
area  for  changes  in  driver  structure  before  compilation. 

The  directory  'ken'  contains  the  source  code  for  the  Unix 
operating  system  with  the  exception  of  device  drivers.  The  source  code 
is  all  in  the  C  language  and  when  compiled  is  the  contents  of  the.  file 
'libl ' . 

The  file  'libl'  is  one  of  the  fundamental  building  blocks  of 
reconfiguration  of  the  Unix  operating  system.  'Libl'  is  a  library  of 
the  compiled  code  in  'ken',  and  is  therefore  accessible  only  through  the 
"ar"  command  which  permits  a  user  to  add,  delete,  or  tabulate  the 
contents  of  the  library. 

The  file  'lib2'  is  similar  to  'libl'  except  that  'lib2' 
contains  the  the  object  code  of  the  driver  routines.  The  SATUCM  version 
of  'lib2'  contains  object  code  of  all  the  drivers  available  to  Unix 
including  not  only  the  contents  of  'dmr'  but  of  'useless'  as  well. 
There  is  no  reason  that  the  'lib2'  file  could  not  be  purged  of  the 
object  code  which  is  not  applicable  to  the  SATCOM  lab,  but  demand  on 


memory  space  has  not  yet  warranted  such  a  house  cleaning  operation.  The 
procedure  to  alter  the  contents  of  a  library  is  different  than  that  for 
a  simple  file.  Library  manipulation  is  discussed  in  the  following 
paragraphs  on  system  reconfiguration. 

The  file  'm40.s'  is  one  of  the  few  assembly  language  programs 
involved  in  the  reconfiguration  process.  It  supplies  a  machine  language 
set  of  functions  necessary  for  the  reconfiguration  of  the  operating 
system.  The  file  'm40.o'  is  the  compiled  object  code  which  is  actually 
used  during  system  configuration. 

The  'l.s'  file  is  the  other  assembly  language  file  involved  in 
the  system  configuration  process.  'L.s'  supplies  interrupt  vector 
information  for  all  the  device  drivers.  The  object  code  version,  'l.o', 
is  used  in  the  configuration  process.  The  Unix  reference  manuals  label 
the  'l.o'  file  as  'low. o'  and  the  'l.s'  file  as  'low. s'.  Use  of  the 
'l.s'  file  is  discussed  in  detail  in  the  following  reconfiguration 
subsection. 

The  'cO.c'  file  contains  the  tables  which  relate  device  numbers 
to  the  driver  routines.  The  Unix  manuals  refer  to  this  file  as  'conf.c' 
which  should  not  be  confused  with  'conf.h'  which  is  a  "header"  file. 
There  are  two  tables:  one  for  block  devices  and  one  for  character 
devices.  The  character  table  is  of  concern  here,  and  it  requires  some 
explanation.  The  character  table  has  five  columns  (plus  a  comment 
column).  Each  row  of  the  table  refers  to  a  particular  device  driver. 
The  entries  in  the  row  determine  which  routines  are  contained  in  the 
driver  (open,  close,  read,  write,  special).  If  the  driver  has  no  open 
or  close  routine  &nulldev  is  entered  in  that  position  of  the  row.  If 


means 


the  device  is  missing  any  other  routine  &nodev  is  entered  «. '  Si 
routine  address).  If  there  are  no  routines  at  all  (the  driver  is  not  in 
use)  &nodev  is  entered  in  all  row  positions.  The  row  number,  starting 
with  zero,  determines  the  device  major  device  number.  For  example,  the 
driver  for  the  line  printer  (lp)  is  in  the  third  row  of  the  table,  so  it 
has  major  device  number  2.  It  has  no  read  or  specia.1  routine  (&nodev) 
and  its  remaining  routines  are  lpopen,  lpclose,  and  lpwrite. 

The  file  ' mkconf. c'  is  the  source  code  for  the  executable  file 
'mkconf'.  The  purpose  of  mkconf  is  to  create  the  'l.s'  and  'cO.c'  files. 
Use  of  this  method  to  reconfigure  the  operating  system  is  limited  to  the 
case  where  complete  regeneration  is  required.  As  long  as  only  one 
driver  iseing  added  to  the  system,  the  easier  tact  is  to  edit  fie  source 
codes  'l.s'  and  'cO.c'  and  recompile  the  object  cooe .  A  leader  to 
'mkconf .c'  should  be  added  in  comment  form  which  explains  that  the 
program  has  be  circumvented  in  the  event  that  future  system  ammenders 
attempt  to  use  an  obsolete  'mkconf'  program. 

There  are  additional  files  which  appear  in  I/O  related  programs 
and  functions  called  header  files.  These  files  always  arc  suffixed  by 
the  letter  "h"  (e.g.,  'param.h')  and  are  picked  up  via  "include  ..."  as 
required  by  tne  program.  Files  'param.h',  'user.h',  'conf.n',  'tty.h', 
and  'buf.h'  are  the  more  recurrent  header  files.  The  reader  may  peruse 
these  at  his  convenience,  but  since  they  play  no  direct  role  in 
reconfiguration,  no  discussion  of  the  header  files  appears  here. 

C.  SYSTEM  RECONFIGURATION 

The  following  stepwise  procedure  to  reconfigure  the  operating  system 
is  designed  for  installing  a  new  I/O  driver  into  the  system  as  opposed 


to  amending  an  existing  one.  Modification,  discussed  in  the  next 
subsection,  uses  some  of  the  following  steps,  and  a  knowledge  of  the 
full  reconfiguration  process  will  make  the  modification  process  easier 
to  understand.  Also,  one  must  be  aware  that  only  the  Super-User  in  Unix 
is  allowed  to  alter  the  operating  system.  Soma  files  will  permit 
editing  from  any  user,  but  most  require  the  Super-Jser. 

1 .  Driver  Installation 

The  first  step  in  reconfiguration  is  to  develop  the  device 
driver  software.  This  development  for  the  GPIB  interface  driver  is 
discussed  in  the  next  section.  The  driver  need  not  have  all  the  bugs 

worked  out  of  it  to  be  installed  in  the  system,  since  the 

reconfiguration  process  only  requires  the  driver  to  be  compilable.  The 
effectiveness  of  the  routines  within  the  driver  will  be  tested  after 
successfull  reconfiguration  and  booting  up  of  the  new  operating  system. 
In  this  procedure  we  use  the  driver  designation  "xx"  so  that  the  C 
language  program  will  be  created  under  the  filename  'xx.c'  .  Since  the 

driver  consists  of  a  set  of  routines  not  attached  to  a  "main"  routine, 

it  is  not  compiled  as  an  executable  program.  In  compiling  the  driver 
'xx.c'  use  the  following  command: 
cc  -c  -0  xx.c 

The  output  of  this  command  is  the  compiled  file,  'xx.o'.  The  two  flags, 
"-c"  and  "-0",  suppress  the  loading  phase  of  compilation  and  optimize 
the  object  code,  respectively.  The  'xx.o'  file  is  compiled  but  not 
executable . 

Once  a  driver  is  ready  for  installation  we  need  to  assign  it  a 
major  device  number.  Additionally ,  if  the  driver  will  service  more  than 


one  of  Che  same  type  of  device,  minor  device  numbers  are  required.  To 
obtain  the  major  device  number,  edit  the  'cO.c'  file  by  inserting  a  row 
in  the  character  table  corresponding  to  the  routines  in  the  driver. 
Placement  of  the  row  is  very  important.  As  discussed  in  the  above 
paragraph  on  the  the  'cO.c'  file,  the  major  device  number  depends  on  the 
location  of  the  row  of  driver  information.  If  the  xx  driver  information 
is  placed  above  that  of  a  driver  being  used  by  the  system  the  major 
device  number  for  the  old  driver  will  increment  by  one,  but  this  will 
not  be  reflected  in  the  'dmr'  directory.  To  avoid  any  problems  place 
the  driver  information  row  below  any  currently  used  drivers  or  append  it 
to  the  bottom  of  the  table.  The  major  device  number  is  now  the  number  of 
the  row  (the  first  row  is  number  0.) 

Now  that  the  driver's  major  device  number  is  known  we  can  enter 
the  name  of  the  driver  into  the  'dev'  directory  usin  the  mknod(VlII) 
command.  Again,  this  command  will  work  only  for  the  Super-User. 
Mknod(VIII)  has  the  form: 

/etc/mknod  xx  c  major  minor 

where  xx  is  the  name  of  our  driver,  "c"  refers  to  a  character  device, 
and  "major"  is  the  major  device  number.  If  there  are  minor  device 
numbers  the  mknod(VIII)  command  is  repeated  for  each  minor  device  number 
starting  at  zero. 

The  directory  'dev'  reflects  both  the  major  and  minor  device 
numbers  which  are  created  by  the  mknod(VIII)  procedure.  One  should 
check  of  the  'dev'  directory  to  insure  that  the  device  name  and 
associated  major  and  minor  numbers  are  indeed  present  in  the  system. 
Having  taken  care  of  the  major  and  minor  device  number  requirements  we 


now  place  the  object  code  of  the  driver  in  'lib2'.  The  means  to  make 
changes  to  a  library  or  archive  is  through  the  "ar"  command.  Append  the 
object  code  of  the  compiled  driver,  'xx.o',  to  'lib2'  by  executing  the 
command : 

ar  r  lib2  xx.o 

Check  the  new  contents  of  the  library  by  typing 
ar  t  lib2 

which  will  list  the  contents  of  the  library.  The  'xx.o'  file  should 
appear  at  the  end  of  the  list  of  contents. 

The  entering  of  the  driver's  interrupt  is  not  dependent  on  the 
successfull  completion  of  all  the  former  compilation  steps.  The  file 
'l.s'  may  be  changed  even  prior  to  writing  the  driver  software.  The  step 
is  placed  here  for  convenience.  The  entrance  of  the  the  device 
interrupt  vector  involves  placing  a  pointer  to  a  callout  routine  and  the 
device's  priority  level  in  the  vector.  The  vector  entries  in  'l.s'  must 
be  in  order  since  the  assembly  language  location  counter  may  not  be 
moved  backwards.  The  Unix  Assembler  Manual  [Ref.  7]  expands  on  the 
restrictions  cf  the  notation  in  'l.s'.  The  second  entry  listed  under 
the  comment  "interface  to  C"  saves  registers  as  required  and  makes  a 
call  on  the  driver's  interrupt  routine.  When  the  routine  returns,  the 
registers  are  restored.  The  syntax  of  making  the  entries  into  the  file 
'l.s'  follows  the  same  style  as  the  other  entries  in  the  file.  When  the 
'l.s'  file  has  been  edited  to  satisfaction  it  should  be  assembled  and 
the  output  moved  to  filename  'l.o'. 

At  this  point  the  driver  has  been  successfully  compiled  into 
'xx.o',  the  character  confguration  table  in  'cO.c'  has  been  changed  and 


compiled  into  'cO.o',  the  'lib2'  file  has  had  'xx.o'  appended  to  it,  and 
the  'l.s'  file  reflects  the  proper  interrupt  vector  and  routines 
assembled  into  the  However,  prior  to  its  use  ensure  that  the  argument 
files  supplied  to  "Id"  are  in  the  working  directory.  If  not,  supply  the 
full  pathname  of  the  file  rather  than  its  ordinary  filename.  Type  the 
command : 

Id  -x  l.o  m40.o  cO.o  libl  lib2 

to  create  a  new  operating  system.  The  'm40.o'  and  'libl'  files  are 
unaltered  versions  of  the  previous  system,  the  ”-x”  flag  saves  some 
space  in  the  output  file  by  preserving  only  external  symbols.  The 
result  of  the  "Id"  command  (if  no  errors  are  encountered)  is  an 
executable  'a. out'  file,  which  may  be  moved  to  the  name  'unix'  in  the 
final  form.  If  there  is  doubt  as  to  the  accuracy  of  'a. out',  it  may  be 
wise  to  change  the  name  to  'xunix'  to  avoid  confusion  with  the  former 
system. 

Once  the  new  operating  system,  'xunix',  has  been  created,  copy 
it  to  the  'root'  directory.  Once  in  the  root,  the  system  may  be  brought 
down  and  rebooted  with  'xunix'  instead  of  the  usual  'unix'.  If  all  is 
well,  and  the  old  system  is  obsolete,  rename  'xunix'  to  'unix'.  The 
main  reason  for  the  renaming  is  that  the  command  "ps"  (process  status) 
must  work  on  the  operating  system  named  'unix',  or  else  the  attempt  to 
execute  the  "ps"  command  results  in  a  "no  swap  device"  response. 

2.  Driver  Modification 

If  an  existing  driver  requires  modification  the  process 
described  above  is  quickly  shortened.  Following  the  same  process,  we 
need  only  edit  the  driver's  source  code  in  the  'dmr'  directory  (where  it 


was  placed  upon  successfull  system  reconfiguration),  and  compile. 
Unless  there  is  a  change  in  the  interrupt  routine,  no  other  source  code 
need  be  altered.  The  changed  driver  is  placed  on  the  end  of  the  '  Lihl' 
file  ("ar  r  xlib2  xx"  will  replace  the  old  driver  code)  and  the  "Id" 
command  is  executed  as  above.  The  remaining  file  shuffling  is  the  same 
as  full  reconfiguration. 

The  driver  for  the  GPIB  was  not  part  of  the  original  library  or 
configuration  table.  Therefore,  the  full  reconfiguration  process  was 
required  for  the  interface  implementation.  The  next  section  discusses 
the  first  step  in  that  reconfiguration:  development  of  the  driver 
software  routines. 


V.  SOFTWARE  IMPLEMENTATION 


Three  essential  areas  to  the  development  of  the  GPIIi  interface  have 
been  discussed:  the  characteristics  of  the  General  Purpose  interface 
Bus,  the  hardware  design  of  the  GPIB  interface  (bkli-C  and  CGI),  and  the 
I/O  requirements  of  the  Unix  operating  system.  These  three  areas 
dictate  the  operational  requirements  of  the  software  necessary  to 
implement  the  interface.  Effective  software  provides  the  user  wi cn  the 
necessary  functions  to  be  able  to  read  from  or  write  to  a  device  on  the 
GPIB  while  working  within  the  Unix  operating  system. 

This  section  covers  two  areas  of  software  development.  The  routines 
in  the  GPIB  device  driver /handler  are  discussed  in  the  first  subsection 
followed  by  a  treatment  of  the  two  header  files  ('iein.h'  and  'ieout.h'; 
which  act  as  software  interfaces  between  the  user's  program  and  the 
driver.  This  report  does  not  contain  a  printout  of  tne  software  for  any 
of  the  three  functions.  The  software  is  available  as  files  in  the  'aoc' 
directory  mounted  on  disk  seven  of  the  workbench  FCP-1J/3+A  in  the 
3ATC0M  lab.  The  source  code  for  the  driver  is  file  'dr.c' ,  which  also 
resides  in  the  'dmr'  directo.  '  as  discussed  in  section  IV.  The  object 
code  'dr. o'  is  appended  to  'lib2'  in  the  'sys'  directory.  The  header 
files  'iein.h'  and  'ieout.h'  also  reside  in  the  'doc'  directory.  They 
have  no  separate  object  code  since  they  are  compiled  at  the  same  time  as 
the  user  program  which  includes  them. 
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A.  GPIB  INTERFACE  DRIVER 


The  GPIB  driver  is  a  file  in  the  Unix  system  containing  five 
routines:  dropenQ,  drcloseO,  arwriteO,  drread(),  and  drint().  Each 
of  these  routines  is  discussed  separately.  The  set  of  driver  routines 
is  preceded  by  a  set  of  constant  definitions  and  structure  assignments. 
The  constant  definitions  take  into  account  the  fact  that  output  from  the 
DR11-C  is  inverted  prior  to  being  echoed  bac.t  to  the  input  register, 
while  input  from  the  GPIB  is  not  inverted  as  it  is  passed  to  the  input 
register  of  the  DR11-C  (see  section  III).  The  constants  prepended  with 
an  'X'  are  bit  inverses  of  their  namesakes  without  the  prepended  'X' 
(e.g.,  XATN  is  the  inverse  of  ATN ) .  The  structure;  system  sets  up  the 
input  and  output  register  aduresses  of  tne  DR11-C  relative  to  the 
defined  value  for  the  control/status  register. 

1 .  Dropen( ) 

The  dropen()  routine  opens  the  GPIB  driver  for  reading  or 
writing.  It  first  checks  to  see  if  anyone  else;  has  control  of  the 
driver  by  determining  if  "dr  1 1 .arstate"  has  a  value  other  than  zero.  If 
it  does,  dropenO  sets  an  error  and  returns  to  the  user  with  a  "-1"  file 
descriptor.  If  "drl I .drstate"  is  zero,  dropenO  clears  the 
control/status  register  which  disables  interrupts.  An  integer  value  for 
a  file  descriptor  is  returned  to  the  user  since  no  error  bit  was  set  by 
dropen().  The  assignment  of  the  value  for  the  file  descriptor  is  made 
by  the  system  open  call  whose  source  code  is  located  in  the  'sys2.c' 
file  in  the  'ken'  directory.  Interrupts  in  the  context  of  this  driver 
are  discussed  in  the  paragraphs  dealing  with  the  drintO  routine. 


2.  Drclose ( ) 


The  drclose()  routine  is  tne  simplest  of  the  driver  routines. 
It  has  one  line  of  code  which  zeroes  the  "drll.drstate"  to  indicate  that 
the  user  has  no  more  use  of  die  driver  and  others  may  access  it. 

3.  Drwrite( ) 

The  drwrite()  routine  takes  a  character  from  the  user's  data 
buffer  (called  'bui'  in  section  IV)  and  places  it  into  the  output 
register  of  the  DR11-C.  It  then  intiates  the  handshaking  process  with 
the  computer  as  the  talker  (see  section  II).  The  routine  loops  through 
this  process  until  one  of  two  terminating  events  occur:  the  number  of 
characters  specified  by  tne  user  to  be  transferred  to  a  GPIB  device  is 
exceeded,  or  the  delimiting  character  is  received  signifying  the  end  of 
the  character  string.  The  standard  C  language  string  delimiter  is  the 
ascii  NULL  character. 

The  system  routine  cpiss ( )  is  used  to  control  the  looping  ana 
place  the  DATA  in  the  DR11-C  output  register.  CpassO  is  described  in 
the  Unix  I/O  manual  [Ref  10:  pp.  2-3].  The  source  code  for  cpassQ 
resides  in  the  the  'subr.c  file  of  the  'ken'  directory.  The  arguments 
of  the  system  write  call  (section  IV)  are  sensed  by  cpass()  which  uses 
the  'nbytes'  argument  to  judge  how  many  characters  should  be  passed  and 
counts  down  from  'nbytes'  for  each  call  on  cpass() .  As  long  as  the  loop 
number  has  not  exceeded  the  'nbytes'  limit,  the  routine  returns  the 
character  in  the  user's  buffer  ('buf'  argument  of  the  write  call).  If 
an  error  occurs  or  the  count  becomes  zero,  the  value  "-1”  is  returned. 

The  drwriteO  routine  uses  the  value  returned  by  cpass()  twice 
in  each  loop.  Initially,  cpass()  takes  a  character  from  the  user's 
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buffer  and  ensures  that  it  is  an  ascii  character. 


Therefore,  no  bit 


masking  is  required  in  drwrite().  If  the  value  returned  from  cpass()  is 
less  than  zero,  there  is  nothing  more  to  write  and  the  drwriteO  routine 
returns.  The  second  use  of  the  returned  value  from  cpass()  is  to  check 
for  tne  NULL  delimiter  at  the  end  of  each  loop.  The  loop  in  the 
drwriteO  routine  is  of  the  do-while  type  to  enable  NULL  to  be  placed  on 
the  GPIB  to  reset,  the  DATA  lines.  If  the  character  returned  from  tne 
cpassO  routine  is  valid  it  is  placed  on  che  DR-11C  output  buffer  and 
the  handshaking  sequence  is  initiated. 

The  GPIB  handshaking  in  software  is  accomplished  through  a 
series  of  bit  checking  and  bit  setting  in  the  DR11-C  input  and  output 
registers,  respectively.  After  the  DATA  is  placed  on  the  DATA  lines  of 
the  output  register,  the  talker  (computer)  tests  the  NRFD  bit  in  the 
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input  register  until  NRFD  is  high.  This  signifies  the  readiness  of  all 
listeners  to  receive  data.  The  DAV  line  of  the  output  register  is  then 
set  high,  which,  through  the  inverters,  is  echoed  to  the  input  register 
as  DAV  iow  (true:  DATA  is  valid).  Once  DAV  is  made  true  on  the  GPIB, 
drwriteO  waits  for  NDAC  to  become  high  in  the  same  manner  as  it  waited 
for  NRFD.  NDAC  high  signifies  that  all  the  listeners  have  accepted  the 
DATA,  so  the  talker  sets  DAV  high,  places  a  new  character  on  the  DATA 
lines,  and  starts  the  cycle  over. 

The  method  of  bit  setting  in  the  input  register  is  somewhat 
complex  due  to  the  inverters  between  the  input  and  output  registers.  To 
set  a  bit  low  in  the  input  register,  the  contents  of  the  output  register 
are  inclusive  OR'd  with  the  defined  constant  representing  the  GPIB 
signal  line  to  be  set  (e.g.,  DAV).  To  set  the  bit  high  in  the  input 
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register,  the  contents  of  the  output  register  are  AND'd  with  the  inverse 
of  the  constant  (e.g.,  XDAV). 


If  the  user  attempts  to  write  to  a  device  on  the  GPIB  which 
does  not  exist  there  is  no  effect  on  the  workings  of  drwrite().  The 
wired  ^1)  characteristic  of  the  GPIB  (see  section  II)  allows  all  the 
listeners  to  respond  to  the  talker,  preventing  the  loop  from  hanging  up 
in  an  attempt  to  sense  a  signal  which  never  comes. 

The  last  action  of  the  drwrite()  routine  is  a  test  of  the 
returned  value  of  cpass()  to  determine  if  the  character  returned  is  the 
NULL  delimiter.  If  it  is  not,  then  the  loop  repeats. 

4 .  Drread ( ) 

The  drreacQ  routine  enables  a  user  to  read  a  string  of  ascii 
characters  from  a  device  on  the  GPIB.  The  routine  transfers  characters 
until  the  ascii  character  Line  Feed  is  detected  as  DATA,  or  the  EOI  (End 
Or  Identify)  bit  of  the  GPIB  is  set  true  in  the  data  node  (ATN  false). 

The  user  may  terminate  the  number  of  charaters  read  before  one  of  these 
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two  conditions  is  met  by  the  selection  of  an  appropriate  integer  for  the 
argument  'ubytes'  in  the  system  read  call.  Section  IV  provides  a  full 
discussion  of  the  read  call  and  the  argument  'nbytes'  used  by  that  call. 

DrreadO  uses  the  system  routine  passc(c),  the  companion  of 
cpassO  discussed  above.  Passc(c)  is  used  in  drreadO  in  a  similar 
manner  as  cpassO  is  used  in  arwriteO,  except  that  passc(c)  takes  data 
from  the  DR11-C  input  register  and  passes  it  back  to  the  user's  buffer 
named  by  'buf'  in  the  read  system  call.  Passc(c)  monitors  the  number  of 
characters  transferred  in  the  same  way  as  cpassO  but  does  not  return 
the  character  transferred  as  cpassO  does.  Rather,  it  returns  the  value 
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"0"  until  it's  counter  determines  that  'nbytes'  have  been  passed  at 
which  time  it  returns  "-1"  as  a  flag. 

The  drread()  routine  uses  a  do-while  loop  similar  to  that  of 
drwrite().  Before  entering  the  loop  the  computer  (as  active  controller) 
sets  NRFD  and  NDAC  both  true  and  resets  the  DATA  lines  false.  Then  ATN 
is  set  false,  which  tells  the  talker  to  commence  sending  data.  The 
listener/talker  relationship  is  established  prior  to  the  call  of 
drreadQ  through  the  drwrite()  routine  (see  the  discussion  of  'iein.h' 
below) . 


The 

processing 

of 

data 

within  the 

drreadO  loop  is  more 

complicated 

than  that 

for 

the 

drwrite( ) . 

In  drwriteO  the  cpass() 

routine  took  care  of  masking  off  the  ascii  characters.  Passc(c)  does 
r.ot.  Second,  the  input  from  the  GPIB  device  is  negative-true  which  is 
not  inverted  prior  to  entering  the  DR11-C  input  register.  Third,  a 
means  must  be  supplied  to  check  to  see  if  the  addressed  device  to  supply 
the  data  is  in  fact  on  the  bus.  An  infinite  waiting  loop  is  possible 
and  must  be  avoided;  yet  some  devices  may  be  slow  to  deliver  data. 
Therefore,  a  limit  to  the  time  for  a  device  to  supply  data  must  be  set. 
Fourth,  in  the  read  mode  the  computer  is  the  listener  and  must  supply 
two  handshake  signals  (NR.FD  and  NDAC)  rather  than  one  (DAV). 

On  the  first  pass  through  the  do-while  loop,  the  drreadO 
routine  checks  to  determine  if  the  device  to  supply  data  is  on  the  bus. 
Using  LCNT  as  a  counter  in  a  bit  checking  loop,  the  computer  waits  for 
the  DAV  line  to  be  set  low  by  the  talker  after  setting  the  NRFD  line 
high  (to  signal  that  the  computer  is  ready  for  DATA).  This  loop  is 


repeated  30U0  times  or  until  DAV  is  sensed  low,  whichever  comes  first. 


The  value  3000  results  in  a  tine  interval  of  approximately  iOO 
milliseconds  and  was  determined  through  trial  and  error  experiment  using 
a  HP-1615A  Logic  Analyzer.  If  DAV  is  not  detected  in  100  milliseconds, 
the  goof()  routine  is  called  to  send  the  character  "?"  to  the  user's 
buffer  and  then  return. 

If  DAV  is  sensed  low  (true)  drwriteQ  sets  NRFD  high  (until  it 
is  finished  reading  in  the  DATA)  and  passes  through  a  second  check  for 
DAV  (used  for  subsequent  loops).  It  then  processes  the  DATA  on  the  input 
register  DATA  lines  to  the  user's  buffer.  The  first  process  is  the 
check  for  a  delimiter  from  the  talker.  If  the  Line  Feed  ascii  character 
or  the  GPIB  End  Or  Identify  bit  is  detected,  the  routine  jumps  to  the 
the  label  "out"  which  supplies  the  NDAC  handshake,  sends  the  user's 
buffer  the  delimiter  NULL,  and  resets  the  bus  prior  to  return.  If  the 
delimiters  are  not  sensed  the  16  bit  word  on  the  input  register  is 
masked  off  to  eight  and  inverted.  The  passe (c)  routine  then  sends  the 
processed  data  to  the  user's  buffer.  After  sending  the  DATA  to  the 
user's  buffer,  drwriteQ  sets  NDAC  high,  which  informs  the  talker  that 
DATA  has  been  accepted.  After  the  talker  recognizes  NDAC  high  and  sets 
DAV  high,  NDAC  is  set  back  to  low.  The  loop  in  drreadQ  is  repeated 
until  the  user's  number  of  characters  are  passed  to  his  buffer,  or  one 
of  the  delimiters  (Line  Feed  or  EOI)  is  received  from  the  device 
supplying  data. 

5.  Drint( ) 

There  is  no  routine  for  interrupts  for  the  GPIB  driver.  All 
exchanges  of  DATA  and  handshaking  are  performed  by  bit  setting  and 
checking  in  the  DR11-C  output  and  input  registers.  The  nature  of  an 


interrupt  on  the  GPIB  is  in  the  form  of  the  SRQ  signal  vhicn  is  designed 
to  inform  the  system  controller  of  a  situation  in  one  of  the  devices  on 

the  bus  which  requires  service,  such  as  a  printer  out  of  paper.  The  SkO 
signal  is  only  a  request  to  the  system  controller  who  must  poll  the  bus, 
serially  or  in  parallel,  to  find  out  which  device  set  SRQ  true.  A 
routine  to  check  SRQ  is  not  included  in  the  current  .Tr:.  ver 
implementation  since  the  read  and  write  routines  are  not  adversely 
effected  by  it.  Subsequent  refinements  of  the  driver  may  contain  suet:  a 
status  checking  routine  as  a  special  function,  (see  section  II). 

Since  no  interrupts  are  used  during  a  read  or  write  transaction 
in  the  driver,  the  interrupt  enabling  bits  in  the  DKli-C  control/st  tus 
register  are  disabled  by  clearing  the  register  in  the  dropen()  routine. 
The  CONCLUSION  section  discusses  possible  alternatives  to  the  abov* 
method  of  reading  and  writing  which  uses  the  concept  of  system 
interrupts  in  the  handshaking  process. 


B.  GPIB  DRIVER  SUPPORT  SOFTWARE 

The  user  has  two  header  files,  'ieout.n'  and  'iein.h',  available  to 
assist  in  the  transfer  of  data  between  the  Unibus  and  the  GPIb.  Use  cf 
the  ieout  and  iein  routines  contained  in  these  files  eliminates  the  need 
for  the  user  to  compound  his  program  with  separate  software  to  set  up 
the  talker/listener  relationship  required  by  the  GPIB.  Header  files 
'iein.h'  and  'ieout. h'  are  appended  to  the  user's  source  code  (after  the 
'main'  routine)  via  the  'include'  method.  Figure  5.1  is  a  simple  source 
code  for  writing  the  string  "12345"  to  a  GPIB  printer  showing  the  use  of 
the  header  file  'ieout. h'  in  the  'include'  format.  Note,  header  files 
must  begin  with  the  character. 


main( ) 

{ 

int  d,L; 
char  *info; 

L  =  8;  /*  length  of  info  to  write  is  8  */ 

info  *  "lZSASXrXn" ;  /*  data  to  write  .is  12345  */ 

d  *  06;  /*  device  number  is  06  */ 

ieout(d,L, info) ;  /*  write  out  the  info  */ 

•} 

//include  "../ieout.h" 


Fig.  5.1  Sample  Program  To  Write  To  a  GPIB  Device 


1.  Ieout  .h 

The  output  support  file,  ' ieout. h',  contains  the  ieout  routine 
which  sets  up  the  computer  as  tne.  talker  and  the  GPIB  device  designated 
by  the  user  as  the  listener.  Ieout  is  of  the  form 
ieout(device .length, array)  where  the  argument  'device'  is  the  listener 
device  number  expressed  as  an  octal  number,  the  argument  'length'  is  the 
length  of  the  user's  string  to  oe  transferred  (including  the  implied 
NULL  delimiter),  and  'array'  is  the  name  of  the  string  to  be  written. 

Ieout  contains  two  write  systen  calls.  The  first  sends  two  bus 
commands  to  set  up  the  talker/listener  relationship  following  the 
UNLISTEN  command.  The  computer  is  designated  as  talker  and  given  talk 
address  code  and  may  be  changed  tc  another  value  using  the  "Ascii 
Character  Set."  [Ref.  3:  pp.  75,76]  Ascii  'U'  should  be  avoided  since 
that  address  is  supplied  by  Hewlett-Packard  as  the  address  for  the 
HP-98034A  Interface  for  the  Hewlett-Packard  desk  top  computer,  HP-9825. 
[Ref  4:  p.  12]  The  listener  address  consists  of  the  argument  'device' 
supplied  by  the  user  GR'd  with  the  basic  listener  designation  code  from 
the  ascii  character  set. 

The  second  write  system  call  in  ieout  sends  the  user's  DATA  to 
the  bus.  In  both  write  calls  the  drwriteO  routine  in  the  GPIB  driver 
takes  the  second  argument  to  be  the  the  address  of  the  array  or  string 
to  be  transferred.  The  remainder  of  the  code  in  the  ieout  routine 
supplies  the  open,  close,  and  file  descriptor  information  required  to 
write  out  DATA.  These  system  calls  are  discussed  in  section  II. 

Figure  5.1  illustrates  the  use  of  ieout  in  a  user  program. 


Execution  of  the  program  prints  the  number  "12345"  on  the  HP-7245B 


printer/piotf.sr  whose  device  number  is  06.  If  the  value  of  'L'  in  the 
program  was  larger  than  8  (the  number  of  characters  in  the  "info" 
string)  the  printout  v/ould  still  be  the  same  since  the  C  language 
supplies  the  NULL  delimiter  automatically  at  the  end  of  a  string.  If 
the  value  of  '1/  is  smaller  than  8,  only  the  designated  number  of 
characters  are  sent  to  the  bus.  Therefore,  'L'  is  recommended  to  be 
assigned  an  integer  value  larger  than  the  number  of  characters  in  the 
string. 

2.  Iein.n 

The  input  support  file,  'iein.h',  contains  the  iein  routine 
which  sets  up  the  talker/listener  relationship  in  the  same  way  as  ieout, 
except  that  the  computer  is  designated  as  listener  and  the  device  to 
supply  DATA  is  designated  as  the  talker.  The  computer  listener  address 
is  directly  related  to  its  talker  address  discussed  above.  The  basic 
address  for  both  cases  is  the  five  least  significant  bits  of  data  on  the 

GPIB  (with  ATN  true).  The  sixth  and  seventh  bits  determine  whether  the 
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five  bits  refer  to  a  talker  address  or  a  listener  address  [Ref  3:  pp. 
52-53).  Iein  is  of  the  form  iein(device , length .array)  where  the 
'device'  argument  is  used  in  the  same  way  as  it  was  in  the  ieout 
routine.  The  'length'  argument  is  used  for  the  same  reason  as  the 
'length'  argument  in  ieout.  Iein  uses  the  arreadQ  routine  as  discussed 
in  the  drreadO  section. 

The  function  of  the  iein  routine  is  similar  to  ieout  in  that  it 
writes  out  the  talker/listener  relationship  and  then  reads  in  the  data 
into  the  user's  buffer.  Ieout  writes  out  the  talker/listener 
relationship  and  the  contents  of  the  user's  buffer  to  the  bus. 


Therefore,  the  two  support  routines,  ieout  and  iein,  provide  the  user 
with  installed  software  to  handle  the  talker/listener  relationship 
assignments.  The  user  need  only  supply  the  required  arguments  to  the 
routines . 

Figure  5.2  is  a  sample  program  that  reads  in  data  from  device 
number  01  into  the  array  "store"  and  subsequently  prints  out  the 
contents  of  "store"  onto  the  console  screen  using  the  "printf"  call. 
In  order  to  read  data,  both  the  iein  and  ieout  routines  are  used. 
First,  ieout  is  used  to  tell  device  number  01  to  supply  data  from  its 
channel  B.  Iein  then  sets  up  the  talker/listener  relationship  and 
receives  the  DATA.  As  with  the  ieout  routine,  the  user  should  provide  a 
large  enough  integer  for  the  'length'  argument  to  cover  the  amount  of 
DATA  anticipated  from  the  talker  device.  If  'length'  is  larger  than  the 
desired  number  the  delimiters  from  the  talker  control  the  loop  in 
drread().  All  instrumentation  on  the  bus  use  some  form  of  ascii  Line 
Feed  as  a  delimiter  (some  in  combination  with  an  ascii  Carriage  Return) 
so  no  errors  are  supplied  to  the  user  in  his  buffer.  Finally,  since 
Doth  iein  and  ieout  are  used  in  the  user's  program,  their  respective 
header  files,  'iein.h'  and  'ieout. h' ,  are  appended  to  the  main  routine 
of  the  user  program. 

C.  SIMIARY 

Three  software  routines  implement  the  interface  between  the  Unibus 
and  the  GPIB.  These  routines  are  based  on  the  requirements  of  the  Unix 
operating  system,  the  GPIB  bus,  and  the  hardware  used  to  interconnect 


main( ) 

{ 

char  *setdev,  *store; 

setdev  ■  "BI\r\n";  /*  message  to  set  up 

device  supplying  store  */ 

ieout(01, 4, setdev);  /*  write  message  to  device  01  */ 

iein(01, 12, store);  /*  read  12  chars  into  "store"  buffer  */ 

printf( "Zs" .store) ;  /*  print  "store”  on  console  */ 

} 

//include  "iein.h" 

//include  "ieout.h" 


Fig  5.2  Sample  Program  To  Read  From  a  GPIB  Device 


two  bus  systems.  The  three  software  routines  are  the  GPIhi  criver  and 


two  support  routines,  ieout  and  iein,  which  interface  the  user  £ 
software  and  the  GPIB  driver. 

The  GPIB  driver  is  a  set  of  five  routines  with  drint()  remaining 
void  but  available  to  be  filled  in  the  event  that  the  driver  is  changed 
to  an  interrupt  driven  handler.  The  current  driver  makes  no  use  of  the 
interrupt  routine  since  the  hardware  interface  was  not  designed  for 
interrupt  implementation.  All  DATA  transfer  and  handshaking  is 
accomplished  through  bit  setting  and  bit  checking  in  the  DR11-C  output 
and  input  registers. 

Two  user  available  header  files  are  supplied  to  assist  the  user  in 
reading  from  or  writing  to  a  GPIB  device.  These  two  files  contain 
software  which  deletes  the  need  for  user  generated  code  to  handle 

t 

talker /listener  relationships  required  by  the  GPIB. 
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The  interface  between  the  Unibus  and  the  General  Purpost  Interface 
Bus  consists  of  two  hardware  modules,  the  DR11-C  and  CCI,  supported  in 
software  by  the  GPIB  driver  and  two  support  routines  contained  in  the 
header  files  'ieout.h'  and  'iein.h'.  This  hardware  and  software  system 
effectively  enables  a  user  to  write  to  or  read  from  a  device  on  the  GPIB 
using  C  language  software  on  the  Unix  operating  system.  The  following 
subsections  discuss  the  advantages  and  disadvantages  of  tht:  installed 
interface  plus  a  comparison  of  it  to  a  commercially  available  product. 

A.  ADVANTAGES 

One  advantage  of  the  GPIB  interface  is  its  hardware  simplicity.  The 
DR11-C  is  a  readily  available  interface  to  the  Unibus  which  requires  no 
hardware  or  software  changes  beyond  the  register  ana  vector  address  wire 
jumper  connections.  The  CCI  board  is  a  channeling  device  wr.th  a  set  of 
inverters  between  the  DR11-C  output  register  and  the  GPIB.  One  driving 
force  in  insuring  simplicity  of  hardware  is  the  limited  physical  space 
available  to  the  CCI.  Since  the  entire  interface  structure  is 
constrained  to  one  hex-height  equivalent  card  in  the  PDP-11  mainframe, 
and  the  DR11-C  takes  up  two-thirds  of  that  room,  the  CCI  is  limited  to 
an  effective  area  of  a  5  by  7  inch  card. 

The  software  to  support  the  hardware  is  also  simple.  Developed 
under  the  requirements  of  the  Unix  I/O  system,  the  GPIB  driver  conducts 
all  read  and  write  data  transfer,  including  bus  commands  and  handshaking 
between  the  input  and  output  registers  of  the  DR11-C.  There  are  no 


complicated  jumps  to  interrupt  routines  or  need  to  put  the  system  to 
sleep  waiting  for  input  or  a  handshake  response. 

The  supporting  "iein"  and  "ieout"  routines  available  for  the  user 
relieve  any  programming  requirements  specific  to  the  GPIB.  The  user 
need  only  supply  the  number  of  the  device  to  receive  or  supply  data,  the 
amount  of  data  for  transfer,  and  the  buffer  from  which  or  into  which  the 
data  flows.  The  supporting  routines  handle  the  GPIB  talker/listener 
assignments  and  manipulate  the  system  open,  close,  read,  and  write 
routines . 

B.  DISADVANTAGES 

Transfer  of  data  on  the  GPIB  is  asynchronous  and  inherently  slow. 
The  handshaking  process  is  only  as  fast  as  the  slowest  device  on  the 
bus.  Under  the  current  system  of  handshaking  through  the  DR11-C  input 
and  output  registers,  the  Unix  operating  system  can  become  bogged  down 
waiting  for  data  transfer  to  flow  over  the  GPIB.  Since  Unix  is  a 
multi-user  system,  the  delay  caused  by  the  slow  GPIB  can  cause 
inconvenience  to  other  users  on  the  system. 

One  possible  alternative  to  correct  the  slowness  problem  is  to  run 
the  handshaking  activity  through  an  interrupt  system.  Such  a  system 
will  require  rewiring  of  the  CCI  since  there  are  currently  no 
connections  to  the  interrupt  lines  of  the  DR11-C  control/status 
register.  Also,  the  software  will  require  modification  to  enable  the 
DAV,  NRFD,  and  NDAC  signals  to  effect  the  control/status  register. 
Though  the  software  and  hardware  will  become  more  complex,  the  tradeoff 
for  a  faster  system  may  be  worthwhile  if  the  use  of  the  GPIB  is 
extensive.  Since  some  devices  on  the  GPIB  have  relatively  slow  data 


rates  (e.g.,  the  printer/plotter),  use  of  the  noninterrupt  driven 
interface  is  optimum  when  multi-user  demands  are  minimum,  or  when  only 
one  user  is  on  the  system. 


Under  the  current  implementation  the  system  controller  and  active 
controller  are  permanently  designated  as  the  computer  (Unibus).  There 
is  no  provision  for  the  oassing  of  control  to  another  device  on  the  bus. 
However,  the  computer  acts  as  a  nonaddressable  listener  if  a  GPIB  desk 
top  computer  (such  as  the  HP-9825)  takes  over  the  bus  when  no  users  are 
transferring  data.  The  hardware  and  software  of  the  GPIB  interface 
leave  the  REN  line  of  the  GPIB  in  the  true  position  so  that  if  another 
computer  is  attached  to  the  bus,  it  need  not  place  the  other  devices  in 
remote. 

Lastly,  the  current  implementation  is  not  able  to  respond  to  a 
service  request  by  a  device  on  the  bus.  There  is  no  provision  for  the 
use  of  a  serial  polL  or  parallel  poll  to  determine  the  source  of  the 
request.  This  deficiency  could  be  corrected  through  a  software  routine 
appended  to  the  driver  as  a  special  function  routine  to  determine  the 
status  of  the  bus. 

C.  COMPARISON  WITH  A  COMMERCIAL  PRODUCT 

Not  surprisingly,  there  are  commercially  available  products  to 
interface  the  Unibus  and  the  GPIB.  One  of  these,  the  GPIB11-1,  is 
manufactured  by  the  National  Instruments  Company  of  Austin,  Texas.  As 
one  may  expect,  the  GPIB11-1  is  promoted  as  a  very  effective  and 
efficient  interface,  clearly  outperforming  the  GPIB  interface  discussed 
in  this  report.  The  notable  differences  between  the  two  interfaces  are 
discussed  below.  In  order  to  compare  and  contrast  the  two  interface 


systems  the  following  definitions  apply:  the  term  GPIB11-1  refers  to 
commercial  product,  while  "the  GPIB  interface"  refers  to  the  subject  of 
this  report. 

The  GPIB11-1  hardware  is  the  same  size  as  the  DR11-C  alone,  a  single 
quad  height  board  which  plugs  into  a  slot  in  the  PDP-11  mainframe.  The 
GPIB  interface  hardware  takes  up  the  equivalent  of  a  hex-height  board. 

The  GPIB11-1  software  includes  a  Jtility  program  and  an  Interactive 
Control  program  in  addition  to  the  Driver  program  containing  C  callable 
subroutines.  The  Unix  driver  is  not  standard  equipment.  However,  it  is 
available  as  an  option.  The  key  differences  in  software  are  that  the 
GPIB1L-1  is  interrupt  driven  and  will  interrupt  the  PDP-11  when: 

(1)  the  GPIB11— 1  is  the  talker  and  is  ready  to  send  data, 

(2)  the  GPIB11-1  is  a  listener  which  has  received  data, 

(3)  the  GPIB11-1  is  an  active  controller  and  a  device  on 
the  bus  has  set  SRQ  true, 

(4)  the  GPIB11-1  is  not  the  system  controller  and  the 
interface  is  being  cleared,  or 

(5)  the  GPIB11-1  is  a  bus  monitor  and  a  command  byte  has 
been  received. 

The  GPIB11-1  is  capable  of  passing  control  of  the  bus  to  any  other 
device  on  the  bus.  The  GPIB  interface  maintains  control  at  all  times. 

The  GPIB11-1  is  capable  of  servicing  a  SRQ  signal  from  any  device  on 
the  bus  via  a  parallel  poll  to  determine  device  status.  The  GPIB 
interface  does  not  service  SRQ. 

The  above  differences  do  not  list  all  the  functions  of  National 
Instruments'  product.  A  full  set  of  hardware  and  software 
specifications  are  available  in  the  National  Instruments  product 
specification  sheet  on  the  GPIB11-1  [Ref.  12]. 

There  is  an  additional  important  difference  between  the  GPIB11-1  and 
the  GPIB  interface:  cost.  With  the  optional  Unix  driver  software  the 


GPIB11-1  costs  $1895.00.  A  version  which  includes  DMA  capablities  costs 
$2695.00.  These  are  costs  to  purchase  one  unit.  The  cost  conceivably 
could  be  lower  if  larger  quantities  are  purchased.  The  DR11-C  can  be 
purchased  for  $400.00  while  the  CCI  is  locally  made.  A  straight  dollars 
and  cents  comparison  of  the  two  systems  is  somewhat  misleading,  since  a 
true  cost  comparison  must  include  time  and  labor  spent  in  the 
development  of  the  device  and  software. 

If  a  decision  is  required  as  to  the  most  cost  effective  interface  to 
use  in  a  Unix  system,  careful  analysis  of  the  needs  of  the  system  is 
necessary.  There  is  no  current  need  in  the  SATC0M  lab  to  pass  control 
of  the  GPIB  to  any  other  device  on  the  bus.  Under  the  current  system 
there  is  no  need  to  control  the  flow  of  data  via  an  interrupt  method, 
unless  significant  inconvenience  to  other  users  is  experienced.  Even  if 
such  need  for  interrupts  arises,  the  current  system  can  be  hardware  and 
software  modified  to  fulfil  the  requirement.  If  a  need  arises  to  poll 
the  devices  on  the  bus  as  a  result  of  a  service  request  (SRQ  set  true), 
the  GPIB  driver  can  be  adapted  with  a  special  function  routine  to  obtain 
the  status  of  the  devices  on  the  bus. 

D.  RECOMMENDATIONS 

The  GPIB  interface  is  recommended  as  the  means  to  transfer  data 
between  the  Unibus  and  the  GPIB  under  the  control  of  the  Unix  operating 
system.  The  additional  features  of  interrupt  control  of  the  data 
exchange  process  and  a  polling  routine  for  service  requests  may  be 
incorporated  into  the  system  without  purchasing  a  commercial  interface. 
The  addition  of  the  special  function  to  poll  for  the  device  setting  SRQ 
may  be  accomplished  without  change  to  CCI  hardware,  since  the  SRQ  line 


is  monitored  by  the  input  register  of  the  DRll-C.  Changing  the  "format 
of  GPIB  handshaking  to  interrupt  control  may  create  a  more  convenient 
system,  but  it  will  be  faster  only  during  times  that  data  actually  flows 
to  or  from  the  GPIB  and  more  than  one  user  is  on  the  system.  The 
exchange  of  data  on  the  GPIB  can  only  proceed  as  fast  as  the  slowest 
listner,  despite  the  method  used  to  implement  the  handshaking.  Changing 
over  to  an  interrupt  driven  system  will  require  hardware  changes  to  the 
CCI  since  the  control/status  register  of  the  DRll-C  has  no  input  from 
the  current  CCI  design. 

It  is  recommended  that  the  installed  system  be  incorporated  as  is 
for  a  test  period  of  time  to  be  determined.  During  the  test  period  the 
need  for  changes  as  discussed  above  may  be  evaluated. 
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